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Abstract 


This  document  is  the  first  in  a  series  of  reports  that  make  up  the  technical  documentation 
library  for  Contract  Request  (Req)  Version  1 .0.  Contract  Req  is  a  component  of  the  Corporate 
Business  Application  Software  System  (C-BASS)  suite  of  applications,  an  integrated  family  of 
Lotus  Notes  and  Web-based  software  for  U.S.  Army  Research  Laboratory  (ARL)  electronic 
workflow  and  task  automation.  The  purpose  of  Contact  Req  is  to  automate  a  portion  of  the  ARL 
contracting  process.  This  report  contains  five  major  segments:  (1)  Problem  Statement, 
(2)  Technical  Approach,  (3)  Project  Management  Approach,  (4)  Product  Assurance,  and 
(5)  Project  Schedule.  Together,  these  sections  give  an  overview  of  Contract  Req’s  purpose, 
identify  organizational  requirements  and  constraints,  develop  a  management  plan,  and  set  forth 
a  timetable  with  major  milestones. 
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1.  Introduction 


This  report  presents  the  development  plan  for  Contract  Requirements  Version  1.0  (hereafter 
referred  to  as  Contract  Req).  This  prototype  will  be  used  at  all  U.S.  Army  Research  Laboratory 
(ARL)  sites.  Additionally,  the  exercise  forms  the  nucleus  of  an  automated  contract  requisition 
system  for  future  use  at  all  ARL  sites  as  a  full  production  system. 

Contract  Req  is  a  component  of  the  Corporate  Business  Application  Software  System 
(C-BASS)  cluster  of  applications,  an  integrated  family  of  Lotus  Notes  and  Web-based  software  to 
support  ARL  electronic  workflow  and  task  automation.  This  suite  of  applications  interfaces  with 
standard  Department  of  Defense  (DOD)  systems  to  provide  functionality  unique  to  research  and 
development  (R&D)  competencies.  Primary  responsibility  for  the  development  of  C-BASS 
resides  with  the  Corporate  Information  and  Computing  Center  (CICC),  Enterprise  Systems 
Division  (ESD). 

1.1  Purpose.  The  purpose  of  Contract  Req  is  to  model  experimentally  a  secure  client/server 
system  that  will  automate  the  preparation  of  the  Contract  Req  package.  The  prototype  approach 
mitigates  risk  by  resolving  unknowns  related  to  new  technologies  being  used  to  build  the  ARL 
Intranet  architecture  and  to  refine  further  previously  specified  user  requirements. 

More  specifically,  Contract  Req  automates  the  capture  of  information  necessary  for  three 
significant,  official  documents  in  the  procurement  process:  (1)  Form  DA  3953,  Purchase  Request 
and  Commitment,  (2)  the  Statement  of  Work  (SOW),  and  (3)  the  Government  Cost  Estimate  [1]. 
Essentially,  Contract  Req  automates  the  Procurement  Data  Package  (PDP)  that  must  be  prepared 
in  the  early  stages  of  the  procurement  cycle.  Figure  1  shows  where  these  items  fit  into  the  total 
contract  life  cycle. 

1.2  Background.  Initiation  of  the  multiple  components  of  the  C-BASS  effort  is  motivated 
by  several  factors.  For  example,  ARL  as  a  whole  continues  to  undergo  a  reduction-in-force,  with 
downsizing  of  Chief  of  Staff  (COS)  organizations  expected  to  be  proportionally  greater  than  other 
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Figure  1.  The  Contract  life  Cycle. 

areas  of  ARL.  However,  automation  tools  such  as  Contract  Req  are  expected  to  lessen  the 
effects  of  the  loss  of  people  by  allowing  for  the  coordination  of  work  regardless  of  geography, 
time  zones,  and  work  schedules. 

Important  preparations  for  increased  automation  of  ARL  business  practices  precede  the 
C-BASS  effort.  Specifically,  the  need  to  disseminate  contract  information  to  requisitioned  and 
managers  has  been  identified  in  studies  going  back  to  1976  at  the  Adelphi  Laboratory  Center 
(ALC)  and  to  1986  as  a  multisite,  corporate  requirement.  Notably,  a  business  process 
reengineering  (BPR)  initiative  defined  a  ‘To  Be”  model  for  the  formal  contracts  process  for  all 
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ARL  sites  [2].  This  BPR  ‘To  Be”  model  serves  as  a  foundational  reference  for  the  processes 
defined  in  the  Contract  Req  automation  effort.  Intended  as  a  preliminary  study  rather  than  a 
working  design  document,  the  BPR  'To  Be"  model  lacks  complete  detail  for  process  automation 
and  does  not  fully  describe  requisitioned’  needs.  Therefore,  further  analysis  is  necessary  in  areas 
selected  for  automation  projects  by  CICC’s  ESD. 

When  completed.  Contract  Req  implements  a  secure  ARL- wide  client/server  system  that 
allows  users  to: 

•  Enter  a  contract  request  electronically, 

•  Attach  the  SOW  and  Cost  Estimate  to  the  contract  request, 

•  Route  the  request  to  the  necessary  functional  users  for  electronic  approval, 

•  Automate  interfaces  to  existing,  standard  legacy  systems,  and 

•  Provide  tracking,  reporting,  and  request  status. 

Contract  Req  will  conform  to  the  ESD  life-cycle  strategy  for  ARL  Intranet  application 
development.  The  project  will  proceed  in  phases,  using  an  incremental,  evolutionary  approach. 

13  Organizational  Responsibilities.  CICC’s  ESD  has  the  responsibility  to  develop  the 
Contract  Req  plan  and  system  for  all  ARL  sites.  The  Acting  Chief  of  ESD  is  Dr.  Dana  Ulery. 

1.3.1  Personnel  Requirements.  The  prototype  project  team  requires  personnel  from  ESD, 
the  Systems  Operations  Branch  (SOB),  COS  Procurement,  other  COS  organizations  (e.g.. 
Financial  Systems),  and  contractors  to  provide  technical  support.  Table  1  suggests  the  project 
personnel  and  their  responsibilities. 

1.3.2  Interfacing  Groups.  The  Contract  Req  project  requires  collaboration  between  ESD 
personnel,  COS  Contracts  Office  personnel,  COS  automation  points  of  contact  (POCs),  SOB 
personnel.  Standard  Army  Automated  Contract  System  (SAACONS)  project  office  personnel, 
and  Standard  Procurement  System  (SPS)  project  office  personnel  Table  2  lists  the  interface 
groups  and  the  roles  they  play  relative  to  this  project. 
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Table  1.  Project  Personnel 


Name 

Organization 

Percent  of  Work 
Time  Committed 
to  Project 

Responsibilities 

Denis  McGurin 

ESD 

80 

Project  Manager,  Project 
Planning,  Analysis, 
Development,  Testing, 
Documentation 

John  Leopard 

ESD 

90  (While  available) 

Analysis,  Development, 
Testing,  Documentation 

Mark  Winsor 

ProVar  (Contractor) 

50 

Analysis,  Development, 
Testing,  Documentation 

Robert  Rosen 

CICC 

2 

Requisitioner 

Requirements 

Barry  Lerman 

cos 

2 

Overall  COS 

Requirements 

COS  Procurement 

5 

Main  POC  in  Procurement 

Robert  Tomko 

COS  Procurement 

2 

BBSai 

Mary  Ellen  Caldwell 

COS  Competition 
Advocate 

2 

User  Requirements 

Joan  LoPresti 

COS  Procurement 

2 

User  Requirements  - 
Contracts 

Debbie  Baggett 

COS  Procurement 

2 

User  Requirements  - 
Purchasing  Office 

Jill  Ortwein 

COS  Procurement 

2 

User  Requirements  and 
Information  Systems 
Environment  Information 

1.4  Current  and  Future  Automation  in  the  Contracts  Arena.  Considerable  automation 
that  supports  formal  contracts  in  the  Government  sector  currently  exists.  Additionally, 
automation  projects  are  underway  at  the  DOD  level  that  will  provide  additional,  near-future 
systems.  All  viable  existing  systems  must  be  taken  into  account  during  the  design  and 
development  of  Contract  Req. 


Any  automated  system  currently  in  production  use  within  the  information  environment  is 
termed  a  'legacy  system."  This  includes  those  developed  by  ARL,  commercial-off-the-shelf 
(COTS)  software  purchased  for  use  by  the  organization,  and  Government-off-the-shelf  (GOTS) 
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Table  2.  Interfacing  Groups 


Group  Organization 

Roles 

Requisitioners 

Directorates,  COS,  CICC 

Provide  Requirements  to  Contracts 
Require  Status  Information  From 
Contracts 

Systems  Maintainers 

SOB 

Knowledge  of  the  Business 
Automation  Systems  Environment 
for  Systems  Currently  Supporting 
the  Contracts  Function,  Turnover 
Criteria,  Assessment  and  Evaluation 
for  Contract  Req  Products.  Provide 
Ongoing  Maintenance  When 

Contract  Req  Versions  Move  From 
Development  to  Production 

Systems  Developers 

ESD,  SOB,  COS 

Contracts 

Creation  of  Automation  Tools 
Supporting  the  Formal  Contracting 
Function 

Business  Analysts 

l 

COS 

Procurement,  Budget,  and  Logistics 
Data  Inputs,  Information 
Requirements,  and  Process 
Knowledge 

SOMARDS  Analysts 

cos 

Interface  to  Standard  Operations 
and  Maintenance  Army  Research 
Development  System  (SOMARDS) 

SAACONS/SPS  Analysts 

cos 

Interface  to  SAACONS  and  SPS 

CICC  Advisory  Council 
(CAC) 

Directorates,  COS,  CICC 

Strategic  Direction,  Alignment  to 
Business  Direction 

software  provided  by  external  government  agencies.  As  soon  as  any  automated  system  moves 
from  development  and  experimental  use  to  full  production  and  maintenance,  it  becomes  a  legacy 
system.  Designs  for  Contracts  Req  take  into  account  two  categories  of  legacy  systems:  in-house 
and  external. 


(1)  In-House  Legacy  System  -  Any  system  developed  by  ARL  or  a  predecessor  organization 
that  is  currently  in  production  use  at  any  ARL  site.  Several  ARL  in-house  legacy  systems 
support  the  contract  life  cycle: 
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•  The  Acquisition  Plan  of  Execution  (APE)  system  is  a  Model  204  (M204)  database  of 
information  about  planned  contractual  actions. 

•  The  CONTRAC  system  principally  contains  milestones  of  contract  development;  it  uses 
the  System  2000  (S2K)  database  management  system  (DBMS). 

•  The  Request  for  Proposal  (RFP)  system  assists  contract  specialists  in  building  the 
contract  document. 

(2)  External  Legacy  System  -  Any  system  acquired  from  an  external  source  (COTS  or  GOTS) 
that  is  currently  in  production  use  at  any  ARL  site.  In  some  cases,  the  use  of  GOTS 
systems  is  mandated  by  higher  headquarters. 

•  SAACONS  is  a  Department  of  the  Army  (DA)  standard  system  that  most  Army 
installations  use.  SAACONS  functionality  has  been  extended  since  its  first  fielding,  and 
it  could  be  further  enhanced  to  handle  more  of  the  functions  of  contract  preparation. 
Since  ARL  uses  a  more  extensive  set  of  functions  and  controls  than  those  covered  in  the 
SAACONS,  the  use  of  SAACONS  at  ARL  in  formal  contracts  is  limited. 

In  addition  to  current  legacy  systems,  future  DOD  or  DA  advancements  in  contract 
automation  must  be  taken  into  consideration — especially  those  systems  that  are  likely  to  become  a 
part  of  ARL’s  production  information  environment.  This  includes  systems  in  development  by 
ARL,  COTS  systems  for  which  an  acquisition  has  been  initiated,  and  GOTS  systems  known  to  be 
mandated  and  to  be  installed  in  the  foreseeable  future. 

Of  note  are  plans  for  the  DOD's  Standard  Procurement  System  (SPS),  which  will  replace 
SAACONS  as  the  DA  standard  procurement  system.  Information  about  SPS  is  incomplete,  but 
the  system  is  reputed  to  provide  even  more  capability  than  SAACONS.  Other  in-house  system 
improvements  and  updating  are  also  underway.  For  example,  ARL  Contracts  Branch  is  rewriting 
the  CONTRAC  system  using  the  Microsoft  Access  DBMS.  Work  is  now  under  way  on  this 
project.  Ms.  Jill  Ortwein  is  the  POC. 
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2.  Problem  Statement 


Contract  Req  provides  an  information  system  that  assists  requisitioned  and  procurement 
personnel  to  process  large  acquisitions  in  a  timely,  efficient,  and  accountable  manner.  As  noted  in 
the  preceding  section,  existing  and  future  legacy  systems  provide  substantial  assistance  within  the 
confines  of  the  procurement  function. 

Referring  back  to  Figure  1,  Contract  Req  addresses  the  portion  of  the  life  cycle  noted  as 
“Procurement  Data  Package”  (PDP)  within  the  dashed  box.  The  key  strategic  requirements  for 
the  prototype  are  to  provide  three  basic  automated  functionalities: 

(1)  To  develop  the  three  requirements  documents  of  the  Procurement  Data  Package  (PDP), 

(2)  To  route  these  PDP  documents  to  ARL  entities  that  must  approve  the  acquisition,  and 

(3)  To  route  the  approved  PDP  to  Procurement. 

Future  versions  of  Contract  Req  will  extend  the  basic  capability  within  this  portion  of  the  life 
cycle  and  undertake  projects  addressing  other  phases  of  die  life  cycle. 

Development  of  Contract  Req  Version  1.0  for  full  production  use  will  be  based  on  an 
evolutionary  development  approach  that  uses  the  Zachman  [3]  architectural  framework  and  an 
iterative,  incremental  life  cycle  model. 

Four  steps — each  characterized  by  specific  activities  and  the  products  produced  by  those 
activities — will  be  used  to  develop  the  prototype: 

(1)  Software  Requirements  Analysis, 

(2)  Design  Analysis, 

(3)  Implementation,  and  , 

(4)  System  Testing. 
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Deliverables  include 


(1)  Software, 

(2)  Structured  specifications  document, 

(3)  Testing  plan,  and 

(4)  User  information  sheet. 

Intermediate  software  components  produced  to  demonstrate  specific  functions  will  include 

(1)  Capability  to  attach  large  text  files  to  the  DA  3953  data, 

(2)  Routing  of  the  whole  Procurement  Data  Package  (PDP)  to  approvers,  and 

(3)  Capability  to  perform  these  functions  in  Lotus  Notes  and  Intranet  environments. 

The  design  documents  for  Contract  Req  will  provide  precise,  detailed  technical  models  and 
processes,  rather  than  ambiguous  English  language  descriptive  text.  They  will  be  appropriately 
brief  and,  like  the  prototype  software,  form  the  nucleus  for  full  system  documentation  [4]. 

3.  Technical  Approach 

In  accordance  with  standard  software  engineering  practices  [5],  critical  decisions  about  the 
technical  approach  to  Contract  Req  development  are  driven  by  (1)  life  cycle  considerations,  (2) 
constraints,  (3)  anticipated  or  unresolved  problems,  (4)  development  environment,  and  (5) 
methodologies  and  development  tools. 

3.1  Life  Cycle  Strategy.  The  life  cycle  approach  being  used  stresses  four  principles: 

(1)  An  architectural  framework  that  explicitly  defines  critical  system  components  from 
multiple  perspectives  and  the  relationships  among  these  components,  in  order  to  ensure 
integration  of  the  business,  operational,  and  computing  models  [6]; 
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(2)  Use  of  COTS  products  wherever  possible  to  reduce  costs  and  improve  reliability  and 
productivity; 

(3)  Evolutionary,  iterative  steps  to  incrementally  build  multiple,  shorter-cycle  products  and  to 
control  risk  [7];  and 

(4)  Reuse  of  existing  software  whenever  possible  to  shorten  the  development  cycle  and 
increase  quality  by  using  previously  proven  components  [8]. 


Contract  Req  Version  1.0  is  the  first  phase  in  the  life  cycle  of  the  full  production  product. 


3.2  Constraints.  Some  central  constraints  are  shown  in  Table  3.  All  elements  in  the 
development  process  have  been  considered  in  order  to  develop  a  realistic  software  design  plan; 
however,  the  following  list  is  not  all-inclusive. 

Table  3.  Constraints 


Constraint 

Explanation 

Incomplete  analysis  in  the 
BPR ‘To  Be”  model 

This  model  provides  a  general  level  of  process  description  and 
flow.  The  software  developed  in  Version  1.0  will  rely  on 
functional  documentation,  examples,  and  input  from  experts,  as 
well  as  the  general  model. 

Unclassified  research  and 
development  (R&D) 
services  contract  focus 

The  user  will  be  able  to  develop  packages  for  unclassified 
services  contracts,  which  represent  a  large  share  of  the  formal 
contracts  and  thus  provide  the  best  benefit  to  requisitioned, 
contracts,  and  the  mission  of  ARL. 

3.3  Anticipated  or  Unresolved  Problems.  Table  4  lists  some  of  the  anticipated  and 
unresolved  problems  that  could  affect  development  and  delivery. 

3.4  Development  Environment.  The  development  environment  consists  of  the  following: 

•  Hardware 

-  Server:  PC,  dual  133-MHz  Pentium  processors,  96  MB  RAM,  (two)  4.5-GB  hard  drives, 
4X  CD-ROM,  4-GB  4-mm  tape  drive,  Ethernet  connection. 

-  Client:  PC  no  lower  than  486,  Pentium  preferred. 


9 


Table  4.  Anticipated  and  Unresolved  Problems 


Problem 

Explanation  and  Mitigation 

Project  manpower 

The  project  is  designed  to  have  a  core  team  of  three 
developers.  Availability  of  manpower  may  delay  project 
completion  or  limit  functionality. 

End  of  fiscal  year 

The  rush  to  spend  funds  before  the  funds  expire  at  the  end 
of  the  fiscal  year  on  October  1  may  make  procurement 
resources  unavailable  to  project  personnel  and  delay  work 
at  that  time. 

•Software 

-  Server:  Microsoft  Windows  NT  Server  4.0,  Lotus  Notes  Server  4.5. 

-  Client:  Microsoft  Windows  95  or  NT  Workstation  4.0,  Lotus  Notes  Desktop  4.5. 

-  Middleware  to  interface  to  legacy  systems  reusing  Buylt  middleware  or  modeled  on  the 
Buylt  middleware  [9]. 

3.5  Activities,  Tools,  and  Products.  Table  5  lists  the  major  activities  and 
methodologies/tools  to  be  used,  as  well  as  the  products  of  each  phase  of  the  development  cycle. 


4.  Project  Management  Approach 


Cost,  schedule,  and  performance  will  be  closely  tracked  to  determine  the  progress  of  the 
proposed  work  [10].  Cost  in  this  project  is  the  person-hours  of  government  employees  and  the 
person-hours  of  contractor  effort.  An  associated  cost  (but  one  not  borne  by  ESD)  is  the  cost  in 
user  areas  to  implement  Lotus  Notes.  Based  on  current  guidelines,  a  schedule  for  Contract  Req 
has  been  developed  and  is  given  in  Appendix  A.  Performance  is  under  the  control  of  ESD  and 
the  Contract  Req  project  manager,  as  long  as  functions  being  developed  by  the  DOD  Standard 
Procurement  System  (SPS)  are  avoided.  ESD  balances  its  projects  across  the  three  dimensions  of 
cost,  schedule,  and  performance.  Since  the  first  two  are  constrained,  the  only  flexibility  is  in  the 
functionality  provided  in  the  first  release. 
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Table  5.  Major  Activities,  Methodology/Tools,  and  Products 


|  Activity 

Methodology/T  ools 

Products  | 

Software  Requirements 
Analysis 

Structured  Analysis  [4,  6-8] 

•  Data  Flow  Model 

•  Data  Model 

•  Structured  Specifications 

Design  Analysis 

Structured  Design  [6-8] 

•  System  Interfaces 

•  Forms  Design 

•  Navigator  Design 

•  Structure  Charts 

Development  and 
Implementation 

Lotus  Notes  application 
development 
[10-11] 

•  Routing  and  Tracking 
Function 

•  Links  to  Other  Systems 

•  Reports 

•  Database  Creation 

•  Forms  Creation 

System  Testing 

•  Software  Engineering  testing 
methods  and  tools 

•  Configuration  Management 

•  Prototype  test  plan 

•  Inspection  summaries 

•  Test  logs 

•  Discrepancy  reports 

•  Configuration  management 
controls 

4.1  Assumptions  and  Constraints.  Two  major  considerations  (multiple  task  assignments 
for  key  team  members  and  minimal  experience  with  Lotus  Notes)  combine  to  maximize  the 
software  engineering  complexity  rating  for  this  project.  When  compared  to  optimal  project 
conditions,  the  marginally  adequate  resource  allocation  and  the  low  level  of  expertise  increase  the 
uncertainty  of  effort  estimate  by  a  factor  of  greater  than  2. 


Most  members  of  the  proposed  project  team  have  some  experience  with  Lotus  Notes 
applications.  However,  their  experience  with  application  development  and  system  administration 
averages  less  than  2  years.  This  circumstance  is  reflected  in  the  projected  schedule  of  activities 
and  milestones. 


Additional  factors  of  resource  scheduling  also  impact  the  development  timeline  given  as  the 
Appendix  in  this  report.  The  Contract  Req  prototype  competes  with  other  high-priority  tasks 
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associated  with  establishing  the  ARL  Intranet,  such  as  the  full  production  version  of  Buylt  (the 
first  in  the  C-BASS  suite  of  applications). 


4.2  Resource  Requirements.  Estimates  of  die  distribution  of  time  and  effort  over  the  phases 
of  the  project  are  listed  in  Table  6. 


Table  6.  Estimated  Distribution  of  Time  and  Effort 


Phase 

Time 

(Percent) 

Effort 

(Percent) 

Requirements  Analysis 

20 

15 

Design  Analysis 

20 

20 

Development  and  Implementation 

40 

45 

15 

15 

|  User  Implementation 

5 

5 

43  Milestones  and  Schedules.  Appendix  A  gives  the  detailed  schedule  for  this  project, 
showing  work  breakdowns,  task  duration,  start  and  end  dates,  task  dependencies,  and  milestones 
(based  on  the  received  guidance  for  the  project  start).  Significant  milestones  include 

•  Completing  software  requirements  analysis, 

•  Defining  system  architecture,  data  description,  user  interface,  and  processing  actions, 

•  Implementing  software  designs  and  link  to  legacy  system, 

•  Bench-testing  and  field-testing  the  prototype,  and 

•  System  production  implementation  at  major  ARL  sites. 

4.4  Metrics.  Metrics  will  be  used  to  monitor  and  manage  progress  and  product  quality.  Both 
objective  and  subjective  data  will  be  gathered  to  develop  and  maintain  a  picture  of  project 
progress  and  health.  Key  project  metrics  and  their  uses  are  listed  in  Table  7. 

4.5  Project  Risk  Management.  An  Information  Technology  (IT)  project's  risk  is  influenced 
by  three  factors:  project  size,  familiarity  with  the  technology,  and  structure  of  the  project  [11], 
Project  size  risk  refers  to  the  size  of  the  project  relative  to  the  experience  of  the  project  team  on 
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Table  7.  Key  Project  Metrics 


Metric 

Frequency 

Use 

Development  task  status 

Weekly 

•  Progress  measurement 

•  Process  control 

•  Design  stability 

Change  management  in 
specifications  and  design 

Biweekly,  or  as  needed 
depending  on  impact 

•  Quality  of  specifications 

•  Quality  of  design 

•  Identify  problems 

•  Identify  need  to  reiterate  a 

previous  phase 

Software  size  estimates 

Biweekly 

•  Measure  progress 

•  Monitor  quality  of  process 

and  design 

Tests 

Weekly 

•  Monitor  progress 

•  Monitor  quality  of  process 

and  design 

other  projects.  Familiarity  with  the  technology  refers  to  the  team’s  experience  with  the  particular 
technologies  to  be  used  on  the  project.  Structure  of  the  project  refers  to  the  control  of  scope, 
performance,  and  the  amount  of  formal  project  management  structure  used  in  the  project.  Table  8 
more  fully  describes  the  risks  associated  with  Contract  Req  Version  1. 


Table  8.  Project  Risk  Analysis 


Factor 

Explanation  and  Mitigation 

Project  Size 

The  project  is  to  be  implemented  for  ARL-wide  use.  ESD 
experience  in  projects  with  multiple-site  use  is  low. 

Familiarity  with  the 
Technology 

ESD  has  less  than  2  years  of  experience  with  Lotus  Notes. 

Project  Structure 

ESD  controls  project  scope,  but  not  schedule,  since  completion 
date  is  directed.  Project  management  structure  will  be  high  in 
order  to  manage  progress  and  prevent  scope  creep. 

The  primary  tool  for  managing  risk  is  the  use  of  disciplined  software  engineering  approaches 
and  methods.  As  mentioned  in  section  4.1,  the  use  of  multiple  new  technologies  coupled  with 
inexperienced  staff  subjects  this  project  to  risk.  However,  the  detailed  technical  models  being 
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developed  in  all  phases  of  the  Contract  Req  project  provide  a  basis  for  assessing  technical  risk. 
Potentially  high-risk  conditions,  whether  technical  or  nontechnical,  will  be  identified  promptly  and 
brought  to  the  attention  of  management  responsible  for  decisions  regarding  project  resources  and 
timing. 


5.  Product  Assurance 

Within  any  software  engineering  project,  quality  assurance  activities  are  integrated  throughout 
the  development  process. 

5.1  Assumptions  and  Constraints.  The  Contract  Req  Version  1  product  will  be  put  into 
immediate  production  use  at  multiple  sites.  Rigorous  testing  is  required. 

5.2  Quality  Assurance.  Weekly  management  reviews  will  be  held  with  CICC  and  COS. 
Direct  interaction  with  customer  representatives  identified  earlier  will  assure  continued  tracking  of 
the  project. 


5.3  Configuration  Management.  The  ESD-developed  configuration  management 
methodology  will  be  employed  in  this  project.  Table  9  lists  the  products  that  will  be  under 
configuration  management  control. 


Table  9.  Products  Under  CM  Control 


_ Product _ 

Software _ 

Software  Development  Plan _ 

Software  Requirements  Analysis  Document 

Data  Flow  Model _ 

Data  Model  _ 

Design  Document _ _ 

Test  Plan _ 

Test  Reports 
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